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DOD  GATEWAY  INFORMATION  SYSTEM  (DGIS)  COMMON  COMMAND  LANGUAGE: 
THE  DECISION  FOR  ARTIFICIAL  INTELLIGENCE 

Allan  D.  Kahn 

Defense  Technical  Information  Center,  Alexandria,  VA. 

January  1988 


I.  INTRODUCTION 


The  Defense  Technical  Information  Center  (DTIC)  of  the  O.S 
Department  of  Defense  (DoD)  has  sponsored  development  of  a  DoD 
Gateway  Information  System  (DGIS)  since  1982.  The  purpose  of 
DGIS  is  to  provide  online,  streamlined  methods  for  identifying 
accessing,  searching  and  analyzing  data  from  heterogeneous 
databases  of  interest  to  the  DoD  community  [CGA85] ,  The 
following  figure  is  the  top  menu  of  DGIS,  and  shows  its  core 
operations  to  achieve  this  purpose  [ RAD36 ] : 
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POD  Gateway  Information  System 


DGIS 


MISSION 


•  Provide  access  to  remote  svstems 

•/ 

•  Aggregate  information  from  those  systems 

•  Process  and  tailor  that  information 


GOAL 


•  Streamlined  system  for  intermediaries  and  end-users 
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COMMON  COMMAND  LANGUAGE 


Barrier: 

•  Piversity  of  information  systems 

•  Learning  requirement/curve 

•  Constrained  information  universe 

Need: 

•  Comprehensive  information 

•  Standard  language 


One  of  the  barriers  to  searching  diverse  databases  is  the 
lack  of  a  common  command  language  set  for  retrieving  in 
heterogeneous  databases.  To  overcome  this  barrier,  the  Program 
Manager  for  the  DoD  Gateway  Information  System  (DGIS)  requested 
that  a  Common  Command  Language (CCL)  design  activity  begin,  and  in 
April  1986  a  team  of  three  people  was  assigned  the  effort. 

Just  prior  to  this  time  a  literature  search  was  made  to  check 
progress  in  CCL  development.  The  review  showed  that  CCL 
literature  was  sparse,  which  portended  that  CCL  applications  were 
not  readily  available  for  DGIS  needs.  A  search  of  the  Library 
and  Information  Science  Abstracts  (LISA)  database  on  DIALOG  in 
February  1986,  for  example,  resulted  in  9  finds,  compared  to  22 
in  January  1988.  This  lack  was  confirmed  by  conversations  with 
people  working  in  the  field,  the  conclusion  being  that  extensive 
CCL  literature  was  only  on  the  verge  of  surfacing.  A  review  of 
the  citations  obtained  showed  us  CCL  had  two  basic  thrusts  at 
that  time:  one  thrust  was  conceptual  dissertation,  the  other  the 
experimenting  with  specific  purposes  in  mind,  rather  than 
general.  This  situation  was  further  highlighted  at  the  DTIC-MIT 
jointly  sponsored  Conference  on  Computer  Interfaces,  Boston,  May 
1986  [ DTIC86 ] ;  of  the  three  papers  submitted  specifically 
addressing  CCL,  one  was  about  gateway  processor  software  for 
retrieving  with  how  CCL  concepts  could  be  incorporated,  one  on 
Issues  raised  by  CCL  standards,  and  one  a  review  of  the  CCL 
standard  drafted  by  the  National  Information  Standards 
Organization  (NISO).  The  absence  of  extensive  and  helpful 
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literature  at  that  time  on  real  applications  amenable  to  DGIS 
requirements  showed  us  that  we  had  the  burden  of  giving 
definition  to  the  organization  of  our  DGIS  CCL  development 
activity. 

II.  OUR  FIRST  PROTOTYPING  DEVELOPMENTS 

Our  initial  effort  to  implement  CCL  was  motivated  by 
beginning  with  a  simple  approach,  and  trying  to  get  several 
prototypes  up  quickly.  We  adopted  the  draft  standard  for  common 
commands  prepared  by  the  National  Information  Standards 
Organization  (NISO)  [NIS086/37],  Programming  was  done  in  C, 
merged  with  two  UNIX  utilities  that  were  immediately  adaptable  to 
CCL  needs.  Those  two  utilities  were  LEX  (generator  of  lexical 
analysis  programs),  and  YACC  (Yet  Another  Compiler-Compiler) 

[ UNIXol ] .  LEX  was  used  for  lexical  analysis  of  the  CCL  prototype 
C  programs,  YACC  for  the  syntactical  analysis.  C  was  used  to 
implement  all  remaining  semantic  processing  and  miscellaneous 
tasks  [ TDTpip] . 

Communications  was  highly  critical.  DGIS  had  NAM  (Network 
Access  Machine)  software  agents  available  in  the  DGIS  software 
for  connecting  users  to  databases  for  native  language  searching. 
NAM  provided  programming  for: 

a.  Establishing  the  connection. 

b.  Validating  user  access. 

c.  Logging  on  to  the  target  database,  including  entry  of  the 
logon  codes. 

The  NAM  agent  was  reviewed  and  found  adaptable  to  CCL  for 
communicating  the  command  and  response  in  searching  the  remote 
database  system  [TDTpip] . 
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Our  first  prototype  was  CCL  for  DIALOG.  DIALOG  was  chosen 
because  it  was  a  system  with  which  many  users  in  the  DoD 
community  are  familiar,  and  find  easy  to  use. 

The  DIALOG  prototype  was  followed  by  BRS ,  NASA-RECON,  and 
DROLS  in  fairly  rapid  succession.  BRS  was  chosen  because  it  was 
a  another  major  vendor  system  with  many  databases,  NASA-RECON 
because  it  was  a  Federal  government  database  system,  and  finally 
DROLS,  DTIC's  database  system. 

III.  FIRST  PROTOTYPE  RESULTS 

He  terminated  C-progr amming  with  completion  of  the  four 
prototypes.  The  experience  we  gained  was  immeasurably  useful. 

The  following  issues  and  features  resulted  from  this  first 
prototyping : 

1.  The  Adaptation  of  the  NAM  Connection  Agent:  As  mentioned 
NAM  software  for  connecting  with  remote  databases  was  already 
available.  Once  the  sign-on  is  completed,  the  user  is  connected 
directly  with  the  database.  The  user  then  invoices  the  CCL 
translator . 

2.  CCL  Invocation:  Currently,  once  one  has  accessed  a 
database  system  through  the  NAM  connection  agent,  one  may  invoice 
the  CCL  translator  with  a  special  key. 

3.  CCL  Translators:  The  creation  of  prototype  CCL 
translators  taught  us  that  each  information  system  is 
individualistic  and  must  be  treated  as  such.  The  translator 
programming  is  totally  dependent  on  command  mapping  requirements 
for  each  system.  The  programmer  must  also  detect  anything 
"hidden"  in  the  target  database  system  that  is  needed  for  a 
response.  The  CCL  translator  is  a  filter  that,  once  activated, 
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COMMON  COMMAND  LANGUAGE 

First  Prototyping 


•  Feasibility 

•  C-Language/UNIX  System 

•  Functions 

•  NISO  standard 

•  Native  to  standard 

•  Connection  -  DIALOG.  BRS,  DROLS,  NASA-RECON 

•  CCL  concepts 


CCL  Protoype  Results 

1 .  Connection  Agent  (NAM) 

2.  CCL  Invocation 

3.  CCL  Translators/Filters 

4.  Native  Command  Option 

5.  CCL  Prompt 

6.  Command/Entiy  Verification /Echo 

7.  Online  Documentation 

8.  Shell  Utilities  Spawning 

9.  Non-NISO  Commands 

10.  NISO  Commands 

1 1.  In-CCL  Menus 

Proto-conclusion: 


Aids  to  help  user  navigate  the 
unfamiliar  system 


intercepts  all  CCL  commands  from  the  user,  translates  the 
command,  sends  the  translation  (i.e.,  the  target  database  native 
command)  for  execution,  and  brings  the  results  back  to  the  user 
lTDTpip] .  The  translator  i3  deactivated  by  the  conventional 
<CNTL>d  (exit  from  a  process). 

4.  Native  Command  Language  Option:  The  option  to  use  the 
native  command  language  was  necessary  when  we  were  prototyping 
only  a  selected  set  of  commonly  used  commands.  The  entry  of  a 
native  command  was  made  very  simple:  at  the  CCL  prompt,  one 
precedes  the  native  command  with  a  backward  slash  (\)  to  tell  the 
translator  that  the  native  command  is  coming,  e.g.: 

CCL  >  \ s  (for  DIALOG  'select') 

5.  The  CCL  Prompt:  The  prompt  'CCL  >'  was  Incorporated  as 
a  reminder  to  the  user  that  one  has  invoked  the  CCL  utility. 

6.  CCL  Command  verification:  When  the  user  invokes  a  common 
command,  the  translation  of  the  invocation  is  echoed  in  the 
database  system  structure,  e.g.,  for  DROLS: 

CCL  >  find  artificial  intelligence  and  psychology 

(echo)  @str@ 

artificial  intelligence 
and 

psychology 

end 

CCL:  Searching. . . 
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The  echo  may  also  be  turned  off,  currently  with  the  command: 

CCL>  noecho  . 

7.  Online  Documentation:  The  HELP  feature  to  show  the  user 

how  to  use  the  CCL.  The  documentation,  in  very  abbreviated  form, 

covers  the  CCL  commands  available.  For  example  (DIALOG): 

CCL  >  help  find 

CCL  format 

find  <term>  ... 

DIAL0G2  format 

select  <term>  . . . 

DESCRIPTION 

Initiate  a  search. 

8.  Shell  Spawning  while,  in  CCL:  He  incorporated  the 
capability  to  exploit  a  UNIX  shell,  file,  or  utility  while  in  the 
CCL.  Use  of  the  capability  is  at  the  user's  discretion;  for 
example,  the  user  may  want  to  list  one's  files  as  a  review 
measure  while  searching  a  database.  The  signal  to  the  CCL 
translator  is  an  initial  bang  (I),  e.g., 

CCL  >  lls  (for  listing  files) 


CCL  >  Jw 


(for  seeing  who  is  on  the  system) 


9.  New  Commands:  In  developing  the  DGIS  CCL  we  found  that 
the  NISO  standard  did  not  cover  several  items  that  we  deemed 
useful.  Osefulness  was  based  on  the  following: 

a.  Functions,  prevalent  in  systems,  that  aided  the  user; 
an  example  is  successive  session  cost  display. 

b.  Functions,  not  prevalent,  seen  as  highly  useful;  e.g., 
listing  the  accession  numbers  of  finds. 

c.  Functions  that  we  found  were  needed  for  an  operative  CCL; 
an  example  is  cancelling  the  translation  echo  display  at 
one's  discretion. 

The  non-NISO  commands  that  we  incorporated  under  the  first 
prototyping  are: 

COMBINE  Oo  Boolean  operations  (and,  or,  not)  on  previously 
created  sets. 

COST  Display  session  cost  thus  far. 

EXECUTE  Execute  a  previously  saved  search  strategy  (in 
target  database). 

LIST  List  accession  numbers  of  search  results. 

NOECHO  Cancel  native  command  function  echo  to  CCL  command 
function . 

10.  NISO  Standard  Common  Commands  incorporated  in  the  First 

Prototyping:  As  we  developed  the  four  prototypes,  we  included 

the  following  commands  to  enhance  the  prototype  capabilities: 
CHOOSE,  HELP,  FIND,  DISPLAY,  RELATE,  FORWARD,  and  BACK.  START 
and  STOP  are  taken  care  of  by  the  DGIS  automatic  connect  and 
disconnect . 


3  70 


11.  CCL  System  Menu  Development:  As  we  progressed  through 
the  four  prototypes,  the  more  unfamiliar  the  database  systems 
became.  The  programmer  in  particular  was  totally  unfamiliar  with 
DROLS .  This  is  a  normal  situation  because  DROLS,  in  addition  to 
being  a  terse,  no-assist  system,  is  a  closed  system  with  a 
relatively  small,  registered  community.  He  was,  therefore,  as  a 
highly  slcilled  technical  expert,  an  ideal  person  to  look  at  DROLS 
and  divine  its  appropriate  functional  CCL  reguirements. 

The  very  terseness  of  DROLS  (including  that  lack  of  a  prompt) 
generated  the  need  to  experiment  with  menu  sets  to  step  the 
unfamiliar  user  through  the  database.  These  menus,  basically, 
provide  functional  information  the  expert  DROLS  searcher  knows, 
but  is  not  on  the  system.  CCL  menu  examples  are: 

When  invoking  CCL  CHOOSE  in  DROLS  without  designating  which 
database  - 
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DGIS 


In-CCL  Menu 


- - 

CCL  >  choose 

Select  one  of  the  following  files: 

1.  Current  Reports 

2.  Technical  Reports 

3.  New  Accessions 

4.  Work  Unite 

Please  enter  your  choice  (1-4)  -  -  >  2 
CCL  >  find  ...  (etc.) 


•  Functional  Information 

•  Not  On  System 
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When  invoicing  CCL  DISPLAY  for  search  results  in  DROLS  withou 


designating  a  display  format  - 


The  inclusion  of  the  menu  sets  aids  the  CCL  user  to  navigate  the 
unfamiliar  system,  and  hopefully  helps  eliminate  the  need  to 
totally  rely  on  user  manuals. 

IV.  MAJOR  PROBLEM 

Bach  prototype  raised  issues  and  problems  which  we  used  to 
refine  the  successive  prototype.  As  the  prototypes  progressed, 
various  problems  in  working  with  them  led  to  solutions  such  as 
HELP  features  and  menus  as  mentioned  above. 

The  major  problem,  however,  surfaced  as  a  result  of  our 
cumulative  experience.  We  learned  that  creating  "Common  Command 
Language"  was  NOT  a  panacea.  Programming  a  "standard"  command 
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CCL  PROBLEM 


•  Information  system  idiosyncracies 

•  Language  substitution 

•  System  formats 

-  Choose 

-  Display 

Proto-conclusion: 

The  problem  is  the  individual  system 
operating  characteristics,  not  commands. 
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CCL-ISSUE  ELEMENTS 


Standard  Language 


•  CCL 


System 


Purpose  of  CCl|s~| 


Proto-conclusion: 


CCLS  must  be  built  to  serve  the  purpose 
of  the  parent  system. 


language  was  in  actuality  only  substituting  one  command  language 
for  another. 

This  was  most  apparent  when  the  DISPLAY  function  is  employed. 
Quite  factually,  if  the  user  does  not  know  the  DISPLAY  formats  of 
an  unfamiliar  system,  one  cannot  see  results.  A  command  with 
less  serious  consequences  is  the  PIND  function.  Osing  PIND,  the 
user  is  very  likely  to  be  able  to  enter  the  query  and  foment 
results.  But  any  function  involving  a  display  is  likely  to  be 
dead-ended  in  no  display.  This  situation  simply  does  not  obviate 
the  need  for  referral  to  a  system's  user  documentation,  which 
gives  Instruction  in  terms  of  its  native  command  language. 

Another  example  is  the  CHOOSE  function.  Some  systems 
identify  databases  by  number,  others  by  acronym.  Por  BRS ,  one 
must  enter  CHOOSE  NTIS;  in  DIALOG,  CHOOSE  6.  The  hydra  of 
options  and  formats  keeps  cropping  up.  Each  system  must  be 
addressed  individually,  with  the  goal  of  having  some  central 
pattern  program  to  draw  upon.  The  crutch  we  used  for  the  C 
language-based  CCL  prototype  is  the  menu. 

The  creation  of  a  CCL  is  only  one  component  of  the  "CCL-need" 
issue.  A  second  component  is  creation  of  a  CCL  System  that 
allows  a  user  to  search  in  unfamiliar  database  systems  without 
needing  to  know  that  system’s  operating  characteristics.  A  third 
component  is  identifying  the  critical  purposes  that  a  CCL  system 
is  to  serve. 

In  the  case  of  DGIS,  the  criteria  for  CCL  purposes  are  the 
DGIS  information  processing  operations,  particularly  in 
postprocessing  downloaded  files.  A  DGIS  postprocessing 
requirement  is  to  have  a  tagged  citation  for  translation. 
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Downloaded  citations  mast  be  translated  into  the  DGIS  standard 
citation  format  before  the  automated  processing  routines  can  be 
applied. 

This  requirement  is  an  example  of  a  criterion  for  a  DGIS  CCL 
system.  The  CCL  system  must  include  function  default  results  for 
those  users  unfamiliar  with  a  database,  particularly  for  DISPLAY. 
The  default,  on  simple  invocation  of  DISPLAY,  will  provide  the 
fully  tagged  citation.  Additional  elements,  such  as  menus  and 
question  prompts,  e.g.,  "DISPLAY  on  last  set?  y/n,"  must  also  be 
incorporated. 

The  case  of  CHOOSE  represents  another  problem  environment. 

In  DGIS  the  solution  is  the  eventual  integration,  of  CCL  with  a 
Directory  of  Online  Resource*,  when  this  is  accomplished,  the 
query  will  be  forwarded,  amtommtically  to  the  relevant  databases 
through  CCL. 

The  reel  demon  for  COL.  has  turn**  oat  to. be*  the-  idiosyncratic 
operating  character i sties-  of-  each  data has*  system. 

V.  TBS  DECISION  POR  ARTIFICIAL  ISTELUGWCE 

1.  TBS  CAOSX 

The  rigidity  and  constraints  oF  a  straight  algorithmic 
program-based  CCL  discovered  during  the  prototypings  led  us  to 
exploring  the  potential  of  artificial  intelligence.  The  natural 
language  and  expert  system  possibilities  of  AI  were  very 
appealing.  Th*  project's  programming  technical  expert  reviewed 
the  main  AI  programming  languages.  His  recommendation  was  to 
explore  AI  applications  with  PROLOG,  a  simple  but  powerful 
relational  programming  language  based  on  the  idea  of  programming 
in  logic  (BA-861. 
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The  initial  technical  reasons  for  selecting  PROLOG  were 
[ TDTpip] : 

a.  The  Reversibility  of  PROLOG:  In  determining  object 
relationships,  a  program  can  be  written  establishing  those 
relationships,  with  the  inverse  of  the  relationship  inherent  in 
the  program. 

b.  Its  Database  Capability:  In  that  PROLOG  has  its  own 
internal  databases,  this  feature  allows  a  PROLOG  program  to 
manipulate  codes  as  relations  that  can  be  asserted  or  deleted. 
PROLOG  incorporation  in  CCL  includes  extending  to  external 
databases,  e.g.,  INGRES  DBMS  in  the  DGIS  software,  to  achieve  the 
flexibility  of  storing  knowledge  in  both  PROLOG  internal 
databases  and  traditional  external  databases.  This  allows 
including  more  powerful  database  technology  in  the  program  system 
for  greater  performance  and  easier  use  of  DGIS  by  the  enduser. 

c.  The  Separation  of  Logic  and  Control:  A  PROLOG  program 
amalgamates  rules  and  facts,  basically  making  one  also  the  other. 
Although  they  are  governed  by  a  default  execution  control,  the 
control  can  be  easily  supplemented  or  replaced  by  more  powerful 
meta-rules  also  coded  in  PROLOG. 

d.  Object  Inheritance  and  Message  Passing:  These  are  two 
powerful  features  of  object  language  methodology.  Both  are 
easily  Implemented  and  embedded  in  PROLOG.  Both  features  are 
elemental  for  the  more  graceful  functioning  of  CCL. 

2.  THE  CONCEPTUAL  RESTRUCTURING  OP  CCL 

Using  C  language  programming,  the  basic  CCL  elements 
consisted  of  the  user,  the  CCL,  the  database  language  processor, 
and  the  database  information  accessed.  The  jump  to  PROLOG  opened 
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new  possibilities  in  which  CCL  now  could  be  handled  as  a 
knowledge-based  system.  The  CCL  conceptual  structure  now  became 

[TDTpipl  : 


To  the  DGIS  user  making  use  of  CCL,  the  fact  that  CCL  will  be 
PROLOG-driven  is  transparent.  The  PROLOG  CCL,  however,  in 
serving  the  user,  will  draw  on  the  command  language  knowledge 
base,  and  also  a  CCL-user  profile  knowledge  base  (still  to  be 
developed).  The  user's  query  and  profile  data  will  be  controlled 
through  the  control  program  blackboard,  which  will  coordinate 
translation  and  communications  in  a  continuous  real-time  system 
mode  t BA-86 ]  through  the  NAM  connection  agent.  The  NAM  agent 
passes  the  communications  to  and  from  the  target  database 
system's  command  language  processor  for  searching  on  the  database 
information. 
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CCLS  -  AI 


With  the  transition  to  an  Al-based  CCL  System,  the  goals  of 
DGIS  CCL  have  been  re-constituted  to  incorporate  Al-supported 
capabilities  as  follows: 

a.  One  command  language  to  communicate  with  all 
bibliographic  databases, 

b.  Creation  a  CCL  System  that  assists  the  user  in  searching 
unfamiliar  database  systems. 

c.  Provision  of  a  user-friendly  search  session. 

d.  Provision  of  an  Intelligent,  user-useful  search  session. 

e.  Flexibility  to  adapt  easily  to  changes  and  enhancements. 

3.  OTHER  CHANGES  IN  THE  ACTIVITY 

Because  of  the  relative  ease  of  learning  PROLOG  programming, 
another  effect  of  making  the  transition  to  PROLOG  was  to  transfer 
much  of  that  programming  from  the  technical  expert  to  the 
requirements  expert.  This  change  allowed  fuller  control  of  the 
command  requirements,  from  command  language  researching  to 
command  language  knowledge  base  building.  This  also  allowed  the 
technical  person  to  concentrate  on  the  knowledge  base  -  database 
system  connector  programs,  in  itself  a  programming-intensive 
activity. 

4.  PUTURB  DIRECTIONS 

Our  next  phase  in  CCL  is  a  melding  of  PROLOG  implementation, 
expert  system  building,  and  C  supplementary  programming.  The 
PROLOG-based  CCL  has  two  parts  {TDTpip] .  One  part  is  fixed,  in 
compiled  PROLOG  code;  the  second  is  variable,  in  interpretive 
PROLOG  code.  The  variable  part  loads  and  processes  information 
from  the  two  knowledge  bases  (KB),  the  command  language  KB  and 
the  user  profile  KB.  Appropriate  tools  will  be  incorporated  to 
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maintain  the  KBs  (adding,  deleting,  modifying  inf orraation) .  We 
are  currently  (December  1987)  procuring  an  artificial 
intelligence  processor  system  and  an  expert  system  building 
software  tool.  The  processor  will  be  networked  to  the  DGIS 
computer  system,  and  will  serve  to  both  develop  and  maintain  Al 
applications  in  CCL  and  other  XI  applications  on  DGIS  [ KAD8 7b ] . 

We  are  investigating  several  schemes  for  KB  organization.  In 
general,  we  plan  to  couple  PROLOG  with  a  Relational  DBMS  (RDBMS) 
where  large  KBs  (most  of  which  are  facts)  will  reside.  The 
technical  issue  here  is  the  interface  between  PROLOG  and  the 
RDBMS  (likely  INGRES).  We  intend  to  make  this  interface  through 
SQL  (standard  query  language)  so  that  it  can  work  with  any  RDBMS, 
rather  than  only  with  INGRES  [TDTpip]. 

Other  CCL  aystem  application  factors  are: 

a.  CCL  Integration  with  Other  DGIS  Punctions:  Other  DGIS 
operations  are  potentials  for  AI  applications,  with  which  to  link 
with  CCL.  One  is  the  DGIS  Directory  of  Online  Resources,  wherein 
a  user's  query  resources  are  identified  and  communicated  with 
automatically  and  simultaneously.  Another  is  the  DGIS 
postprocessing  routines,  with  which  the  multiple  resource 
responses  are  automatically  downloaded,  translated,  merged,  and 
processed  (or  tailored),  based  on  a  one-pass  instruction  entry 
with  which  the  user  invokes  the  whole  process. 

b.  Planning  Capability:  Includes  the  preliminary 
structuring  of  multiple  queries  and  the  combining  of  target 
databases'  result  sets. 
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c.  Learning  Capability  for  CCL:  Employing  learning  solution 
paths  [BA-86]  for  optimizing  the  information  added  to  the  command 
language  KB  and  the  user  profile  KB. 

d.  Migrate  to  Natural  Language:  The  NISO  and  appended  CCL 
will  be  the  backbone  of  the  DGIS  CCL,  but  in  migrating  to  Natural 
Language  dialogue,  will  become  transparent  in  a  command  language 
translation  supporting  role. 

e.  Provide  Simultaneous  Database  Access  Capability:  That 
is,  true  concurrent  connecting  with,  searching  in,  and 
downloading  of  results  from  multiple  systems. 

Considering  these  CCL  application  goals,  the  following 
technical  aspects  that  explain  our  programming  approach  to  the 
DGIS  CCL  interface  are  (and  verbatim  from  [TDT87] ) : 

The  DGIS  CCL  is  structured  as  a  knowledge-based  system.  CCL 
can  be  thought  of  as  a  black  box  between  the  user  and  the  host 
database.  The  control  program  (CP)  of  CCL  is  a  blackboard-baaed 
architecture  PROLOG  program  that  controls  the  interaction  between 
CCL  agents  and  the  communication  agents  (we  use  the  term 
’knowledge  source*  rather  than  agents  to  be  consistent  with  the 
literature  on  blackboard  systems).  There  will  be  two  types  of 
CCL  knowledge  bases.  One  is  pertinent  to  the  user  information, 
and  the  other  is  the  knowledge  base  about  databases.  The  user 
knowledge  base  (OKB)  system  will  store  information  relevant  to  a 
particular  user,  or  a  group  of  users.  Examples  of  information 
stored  in  the  OKB  are  areas  of  interest  (database  names),  short¬ 
hand  (CCL  scripts,  aliases,  et  al.),  user  privileges,  etc.  This 
information  is  needed  by  the  CCL  to  intelligently  converse  with 
and  interpret  commands  from  the  user.  The  database  knowledge 
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base  (DKB)  contains  information  needed  to  translate  CCL  commands 
into  host  database  commands  and  to  understand  the  returning 
results  and  errors  from  the  database. 

The  control  program  (CP)  is  a  typical  blackboard-based 
program.  It  is  a  PROLOG  implementation  of  an  object-oriented 
system  where  the  blackboard  is  nothing  more  than  a  general  object 
that  registers  and  monitors  progress  of  the  related  knowledge 
sources.  Each  knowledge  source  is  an  object  that  is  activated 
and  deactivated  by  messages.  A  knowledge  source's  progress  and 
results  are  also  composed  in  terms  of  messages  whenever  possible 
for  the  blackboard  of  the  CP.  This  includes  the  packaged 
messages  received  through  the  NAM  connection  agent,  already 
mentioned. 

The  construction  of  this  CCL  knowledge  bases  is  being  done 
with  the  aid  of  domain  experts  at  OTIC.  These  experts  help  in 
stating  this  requirements  for  interpreting  the  native  command 
languages,  and  capture  expert  searcher  usage  of  command 
languages.  Additionally,  a  number  of  PROLOG  tools  that  help 
maintain  and  validate  the  knowledge  bases  will  be  Implemented. 

All  this  to  resolve  the  problem  of,  as  the  requirements 
expert  states  [BRL87] :  "Ever  since  the  creation  of  the  second 
online  database  search  system,  the  problem  of  multiple  command 
languages  has  plagued  online  searchers.” 
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